NBS 

PUBLICATIONS 


NRRIR  86-3476 


A 1 1 1 □ 2 L 1 L 5 L 4 


NATL  INST  OF  STANDARDS  & TECH  RI.C. 


All  10261 6564 

Palmer,  Mark  E/The  current  ability  of  th 
QC100  .U56  NO. 86-3476  1986  V19  C.1  NBS-P 


rrent  Ability  of  the 
cture,  Engineering,  and 


Construction  Industry  to  Exchange 
CAD  Data  Sets  Digitally 


Mark  E.  Palmer 


U.S.  DEPARTMENT  OF  COMMERCE 
National  Bureau  of  Standards 
National  Engineering  Laboratory 
Center  for  Building  Technology 
Gaithersburg,  MD  20899 


October  1986 
Final  Report 


Prepared  for: 

QC  al  Civil  Engineering  Laboratory 

100  Hueneme,  CA 

.056 

#86-3476 

1986 

C.2 


NBS 

RESEARCH 

INFORMATION 

CENTER 

NBSIR  86-3476 

THE  CURRENT  ABILITY  OF  THE 
ARCHITECTURE,  ENGINEERING,  AND 
CONSTRUCTION  INDUSTRY  TO  EXCHANGE 
CAD  DATA  SETS  DIGITALLY 


Mark  E.  Palmer 


U.S.  DEPARTMENT  OF  COMMERCE 
National  Bureau  of  Standards 
National  Engineering  Laboratory 
Center  for  Building  Technology 
Gaithersburg,  MD  20899 


October  1986 
Final  Report 


Prepared  for: 

Naval  Civil  Engineering  Laboratory 
Port  Hueneme,  CA 


U.S.  DEPARTMENT  OF  COMMERCE,  Malcolm  Baldrige,  Secretary 

NATIONAL  BUREAU  OF  STANDARDS,  Ernest  Ambler,  Director 


ABSTRACT 


As  the  Architecture,  Engineering,  and  Construction  (AEC) 
industry  continues  to  expand  its  use  of  computer-aided  design 
(CAD)  systems,  the  communication  of  project  information  among 
professionals  and  clients  becomes  more  complex.  The  current 
ability  of  this  industry  to  exchange  CAD  information  digitally 
has  been  assessed  through  discussions  with  AEC  CAD  users  and 
consultants,  site  visits  to  CAD  installations,  and  reviews  of  CAD 
software  and  translator  documentation.  CAD  systems  from 
different  vendors  are  generally  incompatible,  and  this  limits  or 
prevents  the  flow  of  information  between  project  participants. 
The  information  that  is  currently  being  exchanged  between 
different  CAD  systems  is  primarily  graphics,  2-D  drawings  with  no 
attached  databases.  The  received  data  sets  are  usually  only  used 
as  reference  outlines  for  new  work  and  are  not  intended  for 
revision.  The  principal  conclusions  and  recommendations  of  this 
report  are  as  follows: 

1.  In  order  to  take  full  advantage  of  CAD  and  to  maximize  the 
utilization  of  digital  project  information,  the  AEC  industry 
requires  a dependable  method  for  digital  data  exchanges. 

2 . The  current  generation  of  translator  tools  is  inadequate  for 

comprehensive  AEC  CAD  operations.  Incomplete  translators, 
insufficient  documentation,  and  differing  interpretations  of 

specifications  have  prevented  accurate  and  complete  data  set 
exchanges . 

3.  There  is  a critical  need  for  a public  program  to  validate 

translator  software,  to  identify  problems  in  current 

implementations,  and  to  develop  guidelines  for  the  use  of 
computer  data  exchange  standards. 

KEY  WORDS:  AEC  CAD;  CAD  data  exchange;  computer-aided  design; 

computer  integrated  construction;  construction 
documentation;  data  exchange  standards;  data 
translators;  digital  data  interchange;  IGES ; 
intermediate  data  exchange  formats;  validation  of 
translators . 
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1. 


Introduction 


Architecture,  Engineering,  and  Construction  (AEC)  firms  are 
striving  to  increase  their  efficiency  and  to  improve  their 
projects  by  incorporating  computer-aided  design  (CAD)  systems. 
The  percentage  of  A/E  firms  using  CAD  has  been  steadily 
increasing  during  this  decade.  Recent  surveys  of  design  firms 
report  that  40  percent  of  the  responding  firms  currently  have  CAD 
capabilities,  compared  to  15  percent  in  1984.  At  least  80  percent 
of  all  AEC  firms  are  predicted  to  have  CAD  systems  by  1987  [1], 

The  use  of  computers  in  these  organizations  has  been  evolving 
from  separate  computer-aided  drafting,  engineering,  and  project 
management  applications  toward  integrated  CAD  systems,  which 
address  the  full  range  of  AEC  operations.  The  common,  critical 
component  of  all  of  these  systems  is  the  information  that  they 
manage.  The  usefulness  of  CAD  systems  is  directly  affected  by 
how  successfully  this  information  can  be  exchanged  between 
different  systems  and  the  various  project  participants. 

The  purpose  of  this  document  is  to  provide  an  assessment  of  the 
AEC  industry's  current  ability  to  exchange  CAD  data  sets 
digitally  and  to  present  recommendations  for  future  action.  This 
assessment  was  produced  through  discussions  with  AEC  CAD  users, 
consultants,  and  vendors,  site  visits  to  CAD  installations,  and 
reviews  of  CAD  software  and  translator  documentation.  Many  of 
the  discussions  were  conducted  over  the  telephone,  and  all  of 
them  were  structured  upon  a broad  list  of  "AEC  CAD  Data  Exchange 
Questions"  (included  in  this  report  as  Appendix  A)  . 

During  the  period  of  April  - July  1986,  82  AEC  CAD  professionals 
were  contacted  for  their  responses  to  these  questions  and  for  any 
other  pertinent  information  that  they  chose  to  contribute.  These 
contacts  included  representatives  of  34  AEC  organizations  with 
varying  amounts  of  CAD  experience,  16  AEC  CAD  vendors,  7 AEC  CAD 
consultants,  and  6 CAD  service  bureaus.  The  findings  and 
recommendations  of  this  report  were  then  reviewed  by  a panel  of 
currently  practicing  AEC  CAD  professionals. 


1.1  The  Importance  of  AEC  CAD  Information  Exchanges 


In  most  large  AEC  projects,  each  participating  organization 
operates  independently,  exchanging  information  with  the  other 
professionals  in  the  form  of  drawings,  schedules,  and 
specifications.  In  order  to  fully  exploit  the  potential  gains 
offered  by  CAD,  these  professionals  must  be  able  to  exchange  this 
information  in  digital  form.  Currently,  the  primary  deterrent  to 
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AEC  digital  data  exchanges  is  the  limited  capability  to 
communicate  data  between  CAD  systems  from  different  vendors. 

Many  private  sector,  municipal,  and  military  projects  involve 
several  AEC  contractors,  each  of  whom  may  have  a different  CAD 
system.  As  of  April  1986,  there  were  58  different  CAD  systems 
being  offered  for  AEC  operations  [2],  and  other  CAD  vendors  are 
preparing  to  introduce  more  systems  this  year.  Although  there 
are  annual  discussions  at  CAD  conferences  on  the  impending 
shakeout  of  vendors,  the  AEC  CAD  market  continues  to  expand, 
mature,  and  diversify. 

The  increasing  use  of  CAD  systems  is  bringing  fundamental  changes 
in  the  operations  of  AEC  offices  and  in  the  delivery  of  services 
and  projects.  The  effectiveness  of  the  design  and  construction 
process  is,  in  part,  determined  by  the  manner  in  which 
information  is  exchanged  and  manipulated.  In  order  to 
successfully  integrate  CAD  systems,  AEC  organizations  and 
owner/clients  will  have  to  develop  a strategic  conceptual 
framework,  an  industry-wide  descriptive  interchange  language,  and 
comprehensive  operational  procedures  for  exchanging  CAD  data 
sets . 


1.2  Current  AEC  CAD  Information  Exchanges 


With  the  increasing  use  of  computers  in  the  design  and 
construction  process,  there  is  a growing  demand  for  the  exchange 
of  information  in  digital  form,  i.e.,  as  data  sets.  Many  clients 
are  requesting  the  delivery  of  both  conventional  paper,  project 
documentation  (drawings,  schedules,  etc.)  and  the  digital  files. 
Some  clients  are  accepting  the  delivery  of  just  the  project's 
digital  data  sets,  in  a specified  format. 

Many  organizations  have  identified  facilities  management  as  an 
essential  AEC  service  which  should  use  these  new  tools.  Some 
owner/clients  have  extended  their  specifications  for  the  delivery 
of  project  data  sets  to  include  the  "as-built"  data.  These 
updated  data  sets  are  intended  to  be  used  as  the  base 
documentation  for  facilities  management  operations. 
Unfortunately,  the  extra  costs  of  such  requests  have  caused  most 
owners  to  remove  this  requirement. 

Additionally,  since  very  few  project  owner  organizations  have  CAD 
systems  on  which  to  use  the  data  sets,  CAD  data  may  only  be  used 
during  the  design  process.  Due  to  this  short-term  perspective  as 
to  the  value  of  the  CAD  data,  there  is  no  investment  in 
developing  data  sets  which  can  be  exchanged  throughout  the  1 i 1 e 
cycle  of  a project. 

CAD  systems  produce  drawings  and  other  forms  of  project 
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information  quite  efficiently,  but  unfortunately  it  is  still 
difficult  to  transfer  this  graphic  and  non-graphic  data  from  one 
CAD  system  to  another.  Most  CAD  systems  are  incompatible  with 
one  another  since  they  use  different  data  representations  and 
formats.  Although  there  are  procedures  for  exchanging  graphics, 
currently  there  is  no  way  to  guarantee  that  the  graphic  data  can 
be  manipulated  on  the  receiving  system  or  that  the  non-graphic 
data  will  retain  their  meaning. 

At  present,  there  have  only  been  very  limited  CAD  data  set 
exchanges  within  the  AEC  industry.  The  majority  of  these 
exchanges  have  been  between  professionals  who  are  using  the  same 
kind  of  CAD  system  (i.e.,  within  a homogeneous  environment),  and 
the  translated  data  sets  are  primarily  used  only  for 
reference/background  information  or  as  supplementary  archival 
documentation  (and  not  as  the  master  document) . 

Additionally,  the  flow  of  information  has  only  been  in  one 
direction.  The  capability  for  bidirectional  exchanges  of  CAD 
data  sets  is  only  being  exercised  within  the  larger  A/E  firms 
which  work  in  homogeneous  CAD  environments.  The  AEC  industry  is 
just  beginning  to  examine  how  to  use  CAD  for  the  iterative 
refining,  or  cycling,  of  design  solutions  among  all  of  the 
project  participants,  regardless  of  the  differences  in  CAD  tools. 

The  initial  strategy  for  receiving  CAD  data  sets,  on  the  part  of 
the  large  owner/clients,  has  been  to  require  their  projects  to  be 
designed  on  the  same  kind  of  CAD  system  as  they  use  in-house  and 
to  specify  the  delivery  of  the  project  CAD  data  set  in  that 
system's  format.  During  the  past  two  years,  the  limitations  of 
this  strategy  have  been  recognized,  and  the  requirements  have 
been  expanded  to  encourage  a broader  range  of  A/E  firms  to 
participate.  The  more  recent  construction  project  specifications 
allow  the  use  of  subcontractors  and  service  bureaus  to  translate 
the  original  CAD  data  sets  into  the  required  format,  either  by 
direct  translators  or  via  a neutral  format  (specifically  the 
Initial  Graphics  Exchange  Specification,  IGES) . 

In  order  to  transfer  data  sets  stored  in  one  CAD  system  into  a 
different  CAD  system,  a specified  language  and  format  for  the 
exchange  must  be  agreed  upon  by  the  developers  and  users  of  both 
systems.  In  the  case  of  homogeneous  exchanges  (between  the  same 
kind  of  systems) , this  process  is  basically  a direct  transfer  of 
files,  in  their  native  format,  with  no  requirement  for 
translation.  As  long  as  the  representational  conventions  of  the 
data  sets  (i.e.,  assignment  of  layers,  symbol  definitions, 
drafting  standards,  etc.)  are  commonly  defined  for  both  systems, 
this  type  of  exchange  is  usually  successful  within  homogeneous 
environments . 

The  broader  range  of  possible  data  set  exchange  problems  occurs 
within  heterogeneous  environments  (i.e.,  different  CAD  systems 


3 


exchanging  data) . Since  each  system  uses  its  own  concepts, 
terminology,  and  encoding  schemes,  the  original  data  sets  can  not 
be  directly  used  by  the  application  programs  in  the  receiving 
system.  Therefore,  the  original  data  sets  must  be  translated 
into  the  format  of  the  receiving  system. 

The  primary  constraint  to  current  CAD  data  set  exchanges  is  that 
there  has  not  been  a comprehensive  and  acceptable  (dependable  and 
verifiable)  method  for  the  digital  exchange  of  information 
between  different  AEC  CAD  systems.  Successful  AEC  CAD 
information  exchanges  will  require  a documented  taxonomy  of 
modeling  concepts  and  a protocol  to  communicate  each  concept. 
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2. 


Current  AEC  CAD  Systems 


There  are  numerous  CAD  systems  available  to  AEC  organizations, 
ranging  from  simple  drafting  aids  to  integrated  (a  common 
database  management  system  supports  all  intradiscipl inary  and 
interdisciplinary  functions)  multi-user  systems  which  address 
numerous  aspects  of  an  AEC  project.  These  systems  can  generally 
be  classified  as  2-D  drafting  systems,  2-D  drafting  systems  with 
database  management  capabilities,  or  as  3-D  modeling  systems, 
which  include  a database  management  system  (DBMS) . 

Many  AEC  firms  initiated  their  use  of  CAD  with  microcomputer 
drafting  applications.  During  the  past  two  years,  the 
capabilities  and  the  cost-effectiveness  of  these  packages  have 
significantly  increased.  Currently  there  is  a sizeable  market 
for  add-on  packages  which  provide  libraries  of  symbols  and  which 
expand  the  basic  drafting  operations  with  specialized  functions 
(such  as  automatic  dimensioning  or  the  insertion  of  doors  and 
windows) . 

In  the  AEC  CAD  arena  there  is  a growing  appreciation  and  demand 
for  database  management  functionality.  A critical  aspect  of  any 
construction  project  is  the  management  of  information,  and  CAD 
technology  can  provide  powerful  tools  for  controlling  the 
relationships  between  graphics  and  data.  The  addition  of 
database  management  systems  may  allow  the  users  to  make  quantity 
takeoffs,  to  compile  listings  of  components,  and  to  perform 
facilities  management  functions. 

However,  the  capabilities  of  a drafting-based  DBMS  are  limited  by 
the  functionality  of  a 2-D  system.  Since  the  same  information 
may  be  represented  on  different  drawings,  there  will  often  be 
redundant  descriptions  of  a building.  This  redundancy  leads  to 
problems  in  maintaining  the  consistency  and  the  accuracy  of  the 
data  attached  to  the  graphics.  This  fact  enforces  the  convention 
of  considering  2-D  drawings  as  "reports"  extracted  from  an 
integrated,  3-D  building  description. 

A 3-D  modeling  system  maintains  a three-dimensional  description 
of  a building,  which  provides  the  basis  for  the  integration  of 
AEC  CAD  operations.  These  systems  use  wire-frame,  surface,  or 
solid  modeling  methods  (some  systems  will  allow  the  user  to 
select  the  specific  method)  and  usually  provide  common  access  to 
a consistent,  central  database. 

Wire-frame  models  describe  objects  as  a series  of  vertices 
connected  by  edges  and  provide  the  most  rudimentary  3-D 
description  of  a building.  Surface  models  extend  the  wire-frame 
to  include  closed  polygons  as  the  faces  of  3-D  objects  and  allow 
properties  to  be  attached  to  the  faces.  The  most  complete 
representation  is  provided  by  solid  modeling,  which  describes  a 
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building  as  an  assemblage  of  solids  (with  attached  properties) 
and  voids.  The  development  of  a full  3-D  model  of  a building  and 
all  of  its  systems  can  be  difficult  and  time-consuming,  and  the 
information  required  for  such  a representation  can  exceed  the 
normal  scope  of  services  provided  by  an  A/E  firm. 

Due  to  the  large  number  and  variety  of  components  in  a building, 
solid  modeling  is  considered  too  computationally  intensive  for 
efficient  AEC  production  of  drawings  and  project  documentation. 
The  current  focus  in  advanced  AEC  CAD  organizations  is  to  develop 
the  capabilities  of  their  surface  modeling  CAD  systems  into  fully 
integrated  design  and  management  tools. 

Numerous  AEC  firms  first  implemented  CAD  in  order  to  automate 
portions  of  their  drafting  tasks.  Yet,  after  the  first  year  or 
two  of  automated  drafting  and  an  increase  in  computer  literacy, 
many  firms  have  become  dissatisfied  with  this  limited  use  of  CAD. 
An  increasing  percentage  of  current  AEC  CAD  users  are 
investigating  the  integration  of  CAD  within  all  of  their  firms' 
operations.  This  integrated  use  of  CAD  resources  may  include 
project  management,  engineering  and  design,  drafting  and 
documentation  production,  operational  control,  and  strategic 
planning. 

Four  key  elements  have  been  advancing  the  integrated  use  of  CAD: 
the  continuing  decrease  in  the  price-performance  ratio  of  AEC  CAD 
systems,  greater  emphasis  on  3-D  modeling,  more  comprehensive 
implementations  of  DBMS's  for  developing  computerized  project 
databases,  and  the  development  of  , local  area  networks  (LANs). 
The  combination  of  comprehensive  DBMS's  and  the  use  of  LANs 
promotes  dynamic  interference  checking,  more  timely  design 
reviews,  and  the  reduction  of  errors  and  field  rework. 


2.1  The  Range  of  Systems  Used  in  AEC  Organizations 


The  AEC  industry  in  the  United  States  is  extremely  fragmented, 
and  most  firms  are  subject  to  sizeable  fluctuations  in  work  loads 
and  types  of  projects.  With  individual  disciplines  having 
differing  requirements,  no  CAD  system  has  yet  fulfilled  all  of 
the  requirements  for  every  type  of  AEC  firm. 

The  simplest  way  in  which  individual  AEC  firms  have  implemented 
CAD  is  to  use  the  same  system  for  all  of  their  CAD  functions. 
This  is  the  strategy  that  many  small  and  mid-size  (less  than  100 
employees)  firms  have  adopted  during  the  past  two  years,  and  it 
has  proven  particularly  successful  when  the  application  program: 
of  the  selected  CAD  system  can  support  the  majority  of  the  firm's 
requirements . 

Unfortunately,  most  of  the  larger  firms  have  not  had  the  luxury 
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to  choose  that  implementation  strategy.  Many  of  the  larger  firms 
began  investing  (both  resources  and  databases)  in  CAD  five  to  ten 
years  ago,  when  AEC  CAD  systems  were  primarily  extensions  of 
mechanical  and  electronic  engineering  CAD/ CAM  systems.  In  many 
cases,  their  use  of  CAD  has  evolved  out  of  a series  of  separate 
decisions.  As  new  projects  or  work  loads  were  initiated, 
specific  applications  programs,  sometimes  from  different  CAD 
vendors,  were  selected  to  support  the  tasks  of  individual 
divisions  or  to  fulfill  the  requirements  of  the  project. 

This  scenario  has  progressed  in  two  different  directions.  In 
some  large  firms,  multiple  systems  are  used  throughout  the 
organization,  and  the  CAD  managers  allocate  their  computing 
resources  based  on  project  priorities,  requests  from  division 
managers,  contracted  specifications  for  deliverables,  and  the 
optimization  of  resources. 

The  other  way  in  which  multiple  CAD  systems  are  being  used  within 
a single  firm  is  that  each  system  is  dedicated  to  the  operations 
of  a specific  division  (or  divisions) . This  strategy  has  usually 
been  adopted  because,  over  the  years,  individual  divisions  have 
selected  different  systems  which  best  suited  the  way  in  which 
they  were  currently  doing  their  work. 

Some  of  the  larger  AEC  firms  in  the  United  States  are  using  as 
many  as  five  different  CAD  systems  for  in-house  operations,  and 
some  of  those  firms  have  only  recently  decided  to  centralize  the 
management  of  their  CAD  operations.  AEC  organizations  which  use 
multiple  CAD  systems  are  faced  with  significant  challenges, 
ranging  from  the  management  of  multiple  versions  of  company 
standards  to  the  monitoring  the  internal  exchange  of  data  sets 
between  incompatible  CAD  systems. 


2 . 2 Data  Set  Translation  Methods 


Central  to  the  coordinated  use  of  multiple  CAD  systems  and  to  the 
successful  exchange  of  CAD  data  sets  is  the  development  of 
dependable  data  set  translation  methods.  There  are  basically  two 
ways  to  transfer  data  between  incompatible  CAD  systems:  direct 
translation  and  translation  via  an  intermediate  format. 

A direct  translator  is  a software  program  which  converts  data 
sets  from  their  original  format  into  the  specific  format  of  a 
receiving  system.  Although  direct  translators  can  be  an 
efficient  way  to  exchange  data  sets  between  two  systems,  they  do 
not  provide  a viable  strategy  for  exchanging  data  sets  between 
multiple  systems. 

The  writing  of  direct  translators  requires  a complete 
understanding  of  the  internal  data  format  used  by  both  the 
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sending  and  the  receiving  system.  This  information  is  usually 
proprietary,  and  is  subject  to  periodic  revisions.  With  each  new 
revision  to  either  of  the  two  systems,  the  direct  translator  must 
be  revised.  Additionally,  this  strategy  reguires  an  excessive 
number  of  translators  to  support  data  exchanges  between  multiple 
systems.  With  "n"  CAD  systems,  there  must  be  n x (n-1)  one-way, 
direct  translators. 

One  informative  example  of  the  limitations  of  direct  translators 
is  the  experience  of  the  U.S.  Army  Corps  of  Engineers.  The  Corps 
has  maintained  both  neutral  and  direct  translators  to  support  the 
CAD  operations  of  their  Huntsville  Division.  After  incurring 
excessive  development  and  maintenance  costs  to  implement  a direct 
translator,  the  Corps  concluded  that  it  was  "impractical  to 
maintain  a direct  translator  as  a custom  implementation"  and  that 
"neither  vendors  nor  the  Government  can  afford  to  maintain  a 
direct  translator  for  every  combination  of  equipment. " [3] 

The  use  of  neutral  translators  is  intended  to  resolve  these 
limitations.  A neutral  translator  is  based  on  the  concept  of  an 
intermediate  format  and  utilizes  two  programs  (a  preprocessor  and 
a postprocessor)  to  perform  the  translation.  The  preprocessor 
reads  the  format  of  system  A and  writes  into  the  intermediate 
format,  and  the  postprocessor  reads  the  intermediate  format  and 
writes  the  output  into  the  format  of  system  B. 

There  are  several  advantages  to  this  process.  First,  the  writing 
of  either  program  only  requires  an  understanding  of  the  internal 
data  format  of  one  system.  Second,  there  is  only  the  need  for  2n 
programs  (one-way  translators)  for  "n"  CAD  systems,  rather  than 
n x (n-1)  one-way  translators.  Whenever  a CAD  system  is  revised 
only  two  programs  have  to  be  updated,  instead  of  all  direct 
translators  that  work  with  that  system. 

A key  problem  of  neutral  translators  is  the  difficulty  of 
establishing  an  intermediate  format  which  supports  the  features 
of  all  of  the  CAD  systems  and  the  requirements  of  all  of  the 
users.  Consequently,  any  intermediate  format  must  represent  a 
compromise  between  many  systems  and  approaches,  and  the 
intermediate  format  may  not  accommodate  all  of  the  information  in 
an  originating  system. 

The  use  of  an  intermediate  format  can  reduce  the  users'  risks  of 
vendor  dependence  and  can  allow  greater  flexibility  in  the 
utilization  of  CAD  resources.  In  order  for  an  intermediate 
format  to  provide  this  foundation  for  data  exchanges, 
specification  must  be  precise  and  unambiguous,  and  the  CAD 
vendors  (software  developers)  must  interpret  and  implement  the 
specification  uniformly. 

Many  of  the  problems  with  the  current  generation  of  neutral 
translator  software  are  caused  by  dissimilar  interpretations  of 
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the  same  specification.  A critical  component  in  the  successful 
use  of  an  intermediate  format  is  the  establishment  of  methods  for 
validating  translators'  conformance  to  a clear  and  precise 
specification. 


2.3  Existing  Intermediate  Data  Exchange  Formats 


Currently,  there  are  four  intermediate  data  exchange  formats 
available  for  AEC  CAD  communications:  the  Initial  Graphics 
Exchange  Specification  (IGES) , the  CalComp  900-Series  plot  file 
formats,  the  AutoCAD  DXF  file  format,  and  the  Intergraph  Standard 
Interchange  Format  (ISIF)1.  IGES  is  the  only  one  of  these  four 
formats  that  is  maintained  by  a national  committee. 

Each  of  these  formats  are  being  used  for  specific  types  of  AEC 
applications.  In  addition  to  these  public  intermediate  formats, 
some  of  the  larger  AEC  firms  have  established  their  own  "neutral 
file  primitives"  and  database  structures  for  the  internal 
exchange  of  project  data. 

The  Initial  Graphics  Exchange  Specification  grew  out  of  the  work 
done  by  the  Boeing  Corp. , the  General  Electric  Corp.,  the  NASA- 
sponsored  Integrated  Program  for  Aerospace  Vehicle  Design  (IPAD) , 
and  the  U.S.  Air  Force  Integrated  Computer-Aided  Manufacturing 
(ICAM)  program.  Each  of  these  organizations  had  identified  the 
lack  of  a standard  for  the  exchange  of  CAD  graphics  as  a critical 
roadblock  to  moving  toward  computer  integrated  operations. 

IGES  is  an  intermediate  format  for  the  exchange  and  archiving  of 
product  description  data  sets.  This  format  was  designed 
initially  for  the  exchange  of  the  drawings  of  manufactured  parts 
and  has  been  extended  to  include  finite  element  models,  3-D  wire- 
frames, and  process  plant  flowsheet  drawings.  The  user  of  one 
CAD  system  translates  his  system's  data  sets  into  the  IGES  format 
using  a preprocessor.  The  user  of  a different  CAD  system 
translates  the  resulting  IGES-formatted  files  into  his  system's 
format  using  a postprocessor. 

An  additional  goal  of  the  IGES  effort  has  been  the  use  of  this 
format  as  an  archival  file  format.  Since  vendor  products  are 
continuously  evolving,  CAD  users  are  frequently  confronted  with 
the  decision  of  upgrading  their  system  to  the  latest  version  to 


1Certain  commercial  equipment,  software,  or  materials  are 
identified  in  this  paper  in  order  to  adequately  specify  existing 
CAD  software  and  data  exchange  formats.  Such  identification  does 
not  imply  recommendations  or  endorsement  by  the  National  Bureau 
of  Standards,  nor  does  it  imply  that  the  software  or  equipment 
are  necessarily  the  best  available  for  the  purpose. 
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take  advantage  of  new  capabilities  while  risking  the  integrity  of 
archived  databases.  This  issue  of  establishing  a reasonable 
approach  for  storing  neutral  archival  files  in  a database 
management  system  has  not  been  resolved.  At  present,  "the  issue 
of  archival  in  a neutral  format  to  avoid  data  loss  due  to  system 
updates  has  taken  a very  secondary  role."  [4] 

In  early  1980,  the  National  Bureau  of  Standards  published  IGES, 
Version  1.0,  and  in  1981,  this  version  was  approved  as  an  ANSI 
standard.  Version  2.0  was  published  in  February  1983,  and 
Version  3.0  was  published  in  April  1986.  IGES  "will  not  solve 
all  the  information  needs  of  CAD/CAM  systems,  and  it  will  need 
further  extension  beyond  its  current  definition.  However,  IGES 
goes  a long  way  toward  alleviating  the  current  data  exchange 
problems,  and  is  a significant  response  to  today's  needs."  [5] 

The  IGES  standard  is  more  complex  than  the  other  formats,  and  it 
can  represent  sophisticated  data  structures,  such  as  networks, 
connectivity,  and  3-D  surfaces.  Although  IGES  was  initially 
designed  to  support  CAD/ CAM  and  printed  circuit  board  technology, 
Version  3.0  has  been  developed  to  support  a broader  set  of 
applications,  including  AEC. 

In  February  1984,  the  IGES/AEC  Committee  was  established  to 
ensure  that  the  IGES  standard  and  the  next  generation  of  data 
exchange  specifications,  PDES  (Product  Data  Exchange 
Specification) , facilitate  the  electronic  exchange  and  archiving 
of  AEC  projects.  This  committee  proposes  and  implements  specific 
IGES  enhancements  for  improving  data  set  exchanges  among  AEC  CAD 
users  (extensions  are  currently  being  developed  for  incorporation 
into  Version  4.0).  The  second  goal  of  this  committee  is  to 
inform  the  AEC  community  of  the  need  for  consensus  data  exchange 
standards  and  to  maintain  effective  liaison  with  that  community 
and  the  CAD  vendors. 

The  CalComp  plot  file  formats  were  developed  by  the  CalComp  Corp. 
to  support  the  CalComp  900  Series  on-line  and  magnetic  tape 
controllers  for  pen  plotters.  These  are  procedural  files  which 
contain  the  commands  for  controlling  the  movement  of  the  pens  in 
the  plotter.  Since  all  geometric  elements  are  processed  as  2-D 
chains  of  vectors,  all  symbols  and  text  lose  their  meaning. 

The  AutoCAD  DXF  format  was  developed  to  support  the  2-D  graphics 
generated  by  Autodesk's  drafting  software  and  is  being  used  for 
transferring  drawings  to  CAD  systems.  AutoCAD  was  introduced  in 
November  1982  as  a CAD  software  package  for  personal  computers. 
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ISIF  was  developed  by  the  Intergraph  Corp.  and  is  widely  used  for 
exchanging  drawings  generated  on  Intergraph  systems.  This  format 
is  designed  to  work  with  the  files  generated  by  the  Interactive 
Graphics  Design  Software  (IGDS)  and  by  the  Data  Management  and 
Retrieval  System  (DMRS) , the  hierarchical  attribute  database.  It 
can  be  used  to  exchange  2-D  or  3-D  graphics  and  associated 
databases . 
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3. 


Types  of  AEG  CAD  Data  Set  Exchanges 


Data  set  exchanges  between  professionals  in  the  AEC  industry  may 
occur  for  a variety  of  applications  and  often  within  diverse  CAD 
environments.  These  exchanges  may  include  drawings,  equipment 
schedules,  bills  of  materials,  numerical  analyses,  administrative 
information,  and  3-D  models,  and  they  may  happen  both  within  an 
organization  (intra-organizational)  and  between  organizations 
(inter-organizational) . 

While  AEC  CAD  users  want  to  exchange  drawings  with  symbols  and 
dimensions,  CAD  systems  provide  the  facilities  to  create, 
manipulate,  and  exchange  specific  types  of  data.  The  types  of 
data  to  be  exchanged  between  these  systems  are: 

* geometry  (lines,  surfaces,  etc.)  and  location 

* annotation  (text,  dimensions,  etc.) 

* topology  and  structure  (means  of  representing  and 

presenting  information) 

* associativity  (logical  relationships  among  data) 

* property  (information  attached  to  data) 

Combinations  of  these  data  types  are  used  to  digitally  represent 
drawings  and  AEC  project  information  in  the  CAD  systems. 

The  elementary  classification  of  CAD  data  set  exchanges  is  based 
on  the  types  of  CAD  environments  employed,  homogeneous  or 
heterogeneous.  A homogeneous  CAD  environment  includes  only  one 
kind  of  CAD  system.  All  data  sets  are  written  in  the  same  format 
and  are  directly  readable  by  all  of  the  communicating 
workstations.  A heterogeneous  environment  includes  more  than  one 
kind  of  CAD  system,  and  consequently,  the  data  sets  written  by 
one  CAD  system  must  be  translated  in  order  to  be  read  by  a 
different  system. 

The  homogeneous  CAD  environment  provides  the  most  direct  and  the 
least  error-prone  facilities  for  data  set  exchanges.  As  long  as 
comprehensive  CAD  operating  procedures  (such  as  the  assignment  of 
layers  for  specific  types  of  information  and  the  coordinated  use 
of  symbols)  are  implemented  and  enforced,  there  can  be  extensive, 
bidirectional  exchanges  of  CAD  information.  These  may  include 
the  selective  transmission  of  portions  of  CAD  projects  or  the 
transfer  of  a complete  project  data  set. 

Comparatively,  there  are  far  more  problems  with  the  heterogeneous 
CAD  environment.  Since  the  systems  are  structured  differently, 
all  graphic  and  non-graphic  data  must  be  mapped  from  the  storage 
files  of  the  originating  system  to  those  of  the  receiving  system. 
These  mapping  procedures  must  resolve  such  basic  software 
differences  as  conversions  from  3-D  to  2-D,  different  line  and 
font  styles,  and  differences  in  the  assignment  of  layers. 
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In  heterogeneous  environments,  each  time  a CAD  data  set  is 
translated  between  systems,  some  information  may  be  lost.  This 
becomes  especially  detrimental  when  subcontractors  are  providing 
portions  of  the  project  design  and  there  is  a need  for 
bidirectional  exchanges  of  data  sets.  The  common  way  to  work 
around  this  problem  is  to  digitally  exchange  only  those  types  of 
information  common  to  both  systems,  using  predetermined  entities 
and  modeling  conventions  and  to  exchange  the  rest  of  the  required 
information  on  paper. 


3 . 1 The  Use  of  Translators  and  Intermediate  Formats 


Although  vendors  and  users  recognize  the  need  for  dependable 
information  transfers  between  CAD  systems,  they  have  not  always 
agreed  upon  the  solution.  "The  amount  of  work  necessary  to  meet 
IGES  is  extensive,  and  the  resources  the  vendor  is  willing  to 
divert  to  this  activity  are  often  inadequate  for  the  task.  New 
hardware  or  additional  software  features  are  perceived  as  adding 
more  to  the  sales  potential  of  a product  line  than  drawing 
portability.  But  in  fact  this  strategy  results  in  reduction  in 
the  use  of  and  the  market  for  CAD  in  the  construction  industry. 
The  unrestricted  exchange  of  electronic  information  is  in  the 
best  interest  of  the  construction  industry  and  the  CAD  vendors." 
[6] 

Initially  the  larger  vendors  only  promoted  in-bound  direct 
translators  (into  their  systems'  format),  for  obvious  marketing 
reasons.  Some  vendors  considered  out-bound  translators  (from 
their  native  format  to  any  other  format)  to  be  comparable  to 
putting  "a  six  inch  drain  line  into  'their'  customer  base".  Due 
to  the  costs  of  supporting  the  development  of  an  intermediate 
exchange  standard,  such  as  IGES,  many  vendors  initially  resisted 
this  solution  to  CAD  data  exchange  requirements. 

Most  large  AEC  CAD  users  agree  on  the  limitations  of  only  having 
direct  translators.  Although  a direct  translator  can  provide  an 
efficient  way  to  transfer  data  sets  between  two  particular  CAD 
systems,  it  does  not  provide  a viable  strategy  for  exchanging 
data  sets  among  multiple  systems. 

During  the  past  four  years  there  has  been  increasing  pressure  by 
AEC  CAD  users  for  the  development  of  a comprehensive  intermediate 
exchange  format.  This  pressure  has  been  exerted  in  various  ways. 
Most  federal  agencies  and  many  AEC  organizations  are  requiring 
extensive  IGES  capabilities  in  their  future  CAD  procurements,  and 
an  increasing  number  of  RFPs  (request  for  proposal)  for  AEC 
projects  are  specifying  the  delivery  of  project  documentation  in 
IGES  format. 
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For  an  intermediate  format  to  be  successful,  it  must  be 
sufficiently  powerful  to  express  all  the  information  in  the 
originating  system,  without  the  receiver  having  to  know  the 
original  (internal)  file  structure.  No  intermediate  format  has 
as  of  yet  been  fully  successful  in  supporting  the  data  set 
exchange  requirements  of  all  AEC  CAD  users. 

The  early  versions  of  IGES  (Ver.  1.0  and  2.0)  were  inadequate  for 
the  data  set  exchange  requirements  of  the  AEC  industry,  produced 
excessively  large  files,  and  did  not  address  the  archival 
requirements.  Although  IGES  is  intended  to  serve  as  an  archival 
format,  the  primary  focus  of  the  IGES  effort  has  been  on 
successful  system  to  system  communications  using  IGES  translator 
implementations . 

Initially,  many  of  the  vendors  only  implemented  a small 
percentage  of  the  specification  (although  they  would  advertise 
IGES  capabilities)  and  did  not  provide  adequate  documentation  or 
software  tools  for  diagnosing  translation  problems.  These 
limitations  frustrated  many  AEC  CAD  users  and  gave  IGES  a poor 
reputation. 

A key  AEC  example  of  this  situation  is  the  limited  implementation 
of  the  subfigure  entity  in  most  vendor  provided  IGES  translators. 
Each  element  of  data  in  an  IGES  file  is  an  entity,  and  the 
subfigure  entity  is  a collection  of  entities  which  can  be  used  in 
multiple  instances. 

AEC  project  definitions  contain  a large  number  of  repetitive 
elements  which  results  in  frequent  instancing  of  the  same  symbol 
(i.e.,  subfigure  entity).  The  use  of  the  subfigure  entity 
provides  a way  to  retain  the  intelligence  of  the  symbols, 
replicates  what  A/Es  do  in  practice,  and  reduces  the  IGES  file 
size.  This  is  a crucial  issue  for  construction  industry  firms 
that  need  to  exchange  detailed  drawings,  and  yet  many  vendor 
provided  IGES  translators  still  do  not  support  the  subfigure 
entity. 

During  the  past  five  years  (since  becoming  an  ANSI  standard) , 
IGES  has  added  increasingly  sophisticated  capabilities  and  has 
gained  extensive  support.  Some  of  these  enhancements  have  added 
to  the  complexity  and  ambiguity  of  the  specification,  and  this 
has  increased  the  difficulty  of  using  IGES  effectively. 

The  quality  of  IGES  translators  has  significantly  improved  during 
1986,  and  the  Version  3.0  document  has  resolved  some  of  the 
earlier  problems  in  the  specification.  This  new  version  enhances 
the  user  defined  MACRO'S  so  as  to  better  represent  standard  part 
libraries  and  defines  a new  extension  for  External  Reference 
Files.  Additionally,  the  new  version  allows  the  use  of  the 
Compressed  ASCII  Format  as  a means  of  reducing  the  IGES  file  size 
to  one  third  of  its  previous  size. 
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Still,  for  IGES  to  be  completely  successful,  the  vendors  must 
implement  the  specification  uniformly.  "Interpretations  of  the 
specification  can  be  different  because  there  are  ambiguities. 
It's  difficult  to  tell  whose  fault  it  is  (when  there  is  a problem 
in  an  IGES  translation)."  [7] 

Of  the  58  CAD  systems  currently  available  for  AEC  operations,  44, 
over  75  percent,  report  to  support  IGES  capabilities  [2]. 
Additionally,  "Several  companies  with  extensive  in-house  CAD/CAM 
systems  and  proprietary  software,  including  John  Deere,  Ford 
Motor  Company,  General  Electric,  General  Motors,  Lockheed,  Martin 
Marietta,  Structural  Dynamics  Research,  and  Westinghouse  are 
writing  their  own  IGES  translators."  [8] 

Many  large  organizations  have  established  IGES  as  part  of  their 
mid-term  digital  exchange  strategy.  Critical  to  the  most  recent 
gains  in  the  acceptance/implementation  of  IGES  are  the  various 
efforts  undertaken  by  DoE,  DoD,  and  each  of  the  individual  forces 
(Air  Force,  Army,  and  Navy)  to  adopt  IGES  as  part  of  their 
transition  to  an  "integrated  mode  of  operation". 

The  Department  of  Defense  has  established  the  CALS  (Computer 
Aided  Logistic  Support)  program  in  order  to  increase  the 
effectiveness  of  its  communications  and  data  processing  systems 
and  to  move  DoD  into  highly  automated  operations.  "A  key  element 
in  this  program  is  the  development  of  DoD  specifications  for 
digital  delivery  by  industry  of  engineering  drawings, 
illustrations  for  technical  publications,  and  future  product 
definition  data  using  the  Initial  Graphics  Exchange  Specification 
(IGES)  and  the  Product  Data  Exchange  Specification  (PDES) . " 

Office  of  the  Under  Secretary  of  Defense,  September  1985  [9] 

The  CalComp  plot  file  formats  and  ISIF  were  the  first 
intermediate  formats  to  receive  general  acceptance  in  the  AEC 
industry,  and  each  has  supported  specific  CAD  tasks.  The  CalComp 
formats  were  originally  designed  to  only  support  the  transfer  of 
graphic  information  and  has  primarily  been  used  for  graphic 
plotters.  The  development  of  ISIF  grew  out  of  Intergraph's 
applications  software,  which  initially  supported  cartography, 
petrophysical  exploration,  and  utilities. 

ISIF  was  designed  to  be  "format-free"  so  as  to  facilitate  user 
editing.  The  CERL  technical  report  on  graphics  translators 
(November  1984)  states,  "This  capability  has  a price.  First,  the 
non-graphic  information  that  can  be  associated  with  the  graphics 
has  limitations.  Also,  there  is  no  ability  to  provide 
backpointers  in  the  data.  In  the  hierarchical  DBMS  that 
Intergraph  currently  markets,  this  is  not  a problem.  However,  in 
the  network  DBMS  soon  to  be  offered,  the  backpointers  would  be 
lost.  ...  Currently,  the  backpointers  may  be  of  little  use  in 
some  drafting  systems;  this  will  soon  be  a very  important  feature 
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in  design  systems  and  advanced  drafting  systems  as  well."  [3] 
Intergraph  has  continued  to  improve  the  software  tools  which  use 
this  format,  and  ISIF  is  being  used  for  a significant  portion  of 
current  AEC  data  set  exchanges. 

Although  IGES  does  have  limitations,  an  increasing  percentage  of 
AEC  CAD  users  are  integrating  IGES  into  their  data  set  exchange 
operations.  If  the  AEC  CAD  vendors  commit  themselves  to 
providing  comprehensive  implementations  of  the  IGES  specification 
and  if  the  quality  of  the  translation  software  tools  (and 
documentation)  improves  significantly,  IGES  will  offer  a viable 
digital  exchange  mechanism  for  current  AEC  CAD  operations. 
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4. 


The  Current  Ability  of  the  AEC  Industry  to  Exchange  CAD 
Data  Sets 


The  AEC  industry  has  only  recently  embraced  CAD  technology  as  a 
primary  medium  for  producing  future  projects,  and  most  firms  are 
still  investigating  the  issues  of  exchanging  CAD  data.  Many  AEC 
organizations  have  only  recently  started  to  define  and  document 
their  CAD  data  set  exchange  requirements  and  procedures. 

There  is  a general  consensus  in  the  AEC  industry  that  in  order  to 
fully  implement  the  capabilities  of  CAD  technology,  a dependable 
method  of  data  set  exchange  must  be  established.  Fortunately, 
numerous  groups  are  working  on  these  issues,  and  some  resolutions 
are  being  formulated.  These  efforts  include  task  groups  within 
corporations,  professional  societies  (ASCE,  ASHRAE,  ASME,  IES, 
and  AIA)  , federal  organizations  (DoC,  DoD,  DoE,  DoT,  FAA,  U.S. 
Naval  Facilities  Engineering  Command,  and  U.S.  Army  Corps  of 
Engineers) , and  within  large  public  works  projects. 

Currently,  very  few  construction  projects  are  completely  designed 
on  CAD.  The  percentage  of  a project  that  is  done  on  a CAD  system 
is  determined  by  numerous  factors,  including  the  optimization  of 
CAD  resources  within  the  firm  and  the  cost-effectiveness  of  the 
CAD  utilization.  Many  times  CAD  drawings/files  grow  so  large 
that  they  become  unmanageable,  and  therefore,  it  is  cheaper  to 
manually  finish  the  last  5 percent  of  a project's  drawings  and 
hard  copy  documentation. 

The  issues  of  coordinating  the  use  and  control  of  conventional 
hard  copy  with  CAD  databases  are  still  unresolved  in  most  AEC 
organizations.  Some  firms  are  now  developing  "transition 
strategies"  for  evolving  toward  integrated,  CAD  based  operations. 
Most  firms  recognize  that  comprehensive  management  and  archival 
procedures  will  be  needed  so  as  to  ensure  successful  data  set 
exchanges  and  comprehensive  transfers  of  project  deliverables. 

Until  recently,  most  AEC  CAD  systems  supported  very  limited  data 
set  translation  capabilities.  Some  A/E  firms  have  concluded  that 
the  current  generation  of  translation  software  tools  are  either 
insufficient  for  their  requirements  or  just  not  reliable.  This 
has  caused  numerous  A/Es  to  digitize  or  re-enter  data  into  a 
different  format  rather  than  risk  the  expenses  of  translating. 

An  increasing  number  of  AEC  clients  are  requiring  the  delivery  of 
CAD  data  sets  in  a specified  format,  in  addition  to  conventional 
drawings.  Many  AEC  firms  are  sending  CAD  data  sets  to  project 
participants,  both  by  using  the  same  kind  of  CAD  systems  and  by 
using  direct  translators.  A few  AEC  organizations  have  recently, 
successfully  implemented  IGES  capabilities  for  exchanging  limited 
subsets  of  project  databases.  Each  of  these  IGES  implementations 
have  required  cycles  of  start-up  testing  and  the  "tailoring"  of 
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the  IGES  translators  to  the  requirements  of  the  specific 
projects,  so  as  to  maximize  the  amount  of  data  that  can  be 
transferred. 


4.1  Types  of  Information  Being  Exchanged  Digitally 


The  information  that  is  being  exchanged  between  dissimilar  CAD 
systems  is  primarily  graphics,  2-D  drawings  with  no  attached 
databases.  This  may  include  geometry  (points,  lines,  arcs, 
etc.),  annotation  (text,  dimensions,  etc),  associativity  (logical 
relationships  among  geometry  entities) , and  display  information 
(line  weight,  font,  etc.).  The  most  common  uses  of  AEC  CAD  data 
set  translations  are  for  transferring  reference  outlines  and 
title  blocks  between  project  participants,  for  the  delivery  of 
the  project  documentation  to  the  client,  and  for  transferring 
mapping  and  finite  element  modeling  (FEM)  information. 

The  acquisition  of  topological  and  topographic  information  has 
become  an  important  element  in  the  use  of  CAD  in  civil 
engineering  and  cartography.  With  the  ongoing  advances  in 
photogrammetry  and  digital  mapping  systems,  there  is  an 
increasing  use  of  translators  to  port  digitized  terrain  models 
into  CAD  systems  (as  base  documentation  for  civil  engineering 
projects) . 

Some  AECs  are  experimenting  with  exchanging  existing  hard  copy 
drawings  by  using  digital  imaging  scanners.  This  procedure 
converts  a raster  image  into  vectors  which  can  then  be  translated 
into  IGES  or  into  the  native  format  of  some  CAD  systems. 

Although  there  is  strong  interest  in  exchanging  complete  CAD 
models  and  their  attached  databases,  successful  exchanges  of 
graphic  and  non-graphic  data  have  only  occurred  in  homogeneous 
environments.  These  exchanges  have  included  2-D  drawings,  bills 
of  materials,  material  standards,  and  schedules.  Although  the 
current  IGES  specification  can  transfer  drawings  to  different  CAD 
systems,  it  is  inadequate  for  transferring  much  of  the 
intelligence  behind  those  drawings. 

The  AEC  industry  is  in  the  transition  to  CAD-based  operations, 
and  most  firms  are  still  examining  their  options  for  transferring 
information  between  CAD  systems.  The  most  extensive  interchanges 
of  AEC  CAD  data  sets  have  occurred  in  homogenous  environments, 
and  these  exchanges  have  included  2-D  drawings,  networks,  and 
attached  databases  (bills  of  materials,  schedules,  etc.).  Except 
for  some  recent  RFPs ' qualification  procedures  and  the  testing  of 
translators,  almost  all  AEC  CAD  data  set  exchanges  have  been  in 
only  one  direction.  As  of  yet,  there  have  not  been  requirements 
for  the  cycling  or  iterative  exchanges  of  AEC  CAD  data  sets. 
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4 . 2 Data  Exchange  Problems  and  Issues 


As  long  as  the  representational  conventions  of  the  data  sets 
(modeling  conventions)  are  commonly  defined  for  both  systems  and 
transmission  protocols  are  established,  homogeneous  data  set 
exchanges  will  have  minimal  problems.  Comparatively,  the 
exchange  of  information  between  dissimilar  AEC  CAD  systems  (i.e., 
within  heterogeneous  environments)  involves  several  potential 
problem  areas. 

With  just  drafting  systems,  these  problems  include  differences  in 
functionality  and  terminology  (levels/layers  or  drawing/view) , 
entity  mismatches,  conflicting  model  sizes  and  scales,  and 
incompatible  line  styles,  fonts,  and  symbols.  The  data 
translation  problems  become  far  more  complex  when  exchanging 
information  between  3-D  modeling  and  engineering  software 
systems . 

The  principal  cause  for  these  problems  is  differences  in  the 
logical  structure  of  the  CAD  systems  (such  as  subfigure  and 
connectivity  definitions) . Most  early  CAD  systems  were 
computerized  drafting  systems  which  only  produced  2-D  drawings. 
The  more  advanced  CAD  systems  now  work  with  3-D  models  of 
building  projects,  from  which  2-D  drawings  can  be  extracted.  A 
2-D  system  will  never  be  able  to  accurately  receive  or  manipulate 
a 3-D  model.  A 3-D  system  can  receive  a 2-D  drawing  and  extend 
it  into  the  third  dimension  by  adding  a "z"  coordinate,  but  that 
extension  will  only  create  a subset  of  any  complex  3-D  model. 

Other  types  of  structural  differences  between  CAD  systems  are 
their  use  of  attached  databases  and  the  structure  of  the  data 
components.  Each  CAD  system  employs  a different  database 
management  strategy  for  managing  the  non-graphic  data  (product 
specifications,  responsibility  assignments,  procurement  dates, 
etc.)  that  are  attached  to  the  graphics.  All  of  these  factors 
can  make  the  exchange  of  CAD  data  sets  between  different  systems 
extremely  problematic.  When  these  problems  are  combined  with  a 
lack  of  common  modeling  conventions,  it  is  extremely  difficult  to 
exchange  useful  information. 

Generally,  there  has  been  marginal  success  with  heterogeneous 
exchanges  via  an  intermediate  format.  The  received  data  sets  are 
usually  used  as  reference  outlines  for  new  work  and  are  not 
intended  for  revision.  Some  common  problems  are: 

* problems  with  units  of  resolution,  scale,  and 
positional  units;  e.g.,  match  lines  do  not  match-up  on 
segmented  drawings. 
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* entity,  symbol,  and  subfigure  mismatches;  e.g., 
parts  of  drawings  are  missing,  title  blocks,  text,  and 
dimensions  are  incorrectly  positioned. 

* crosshatching,  certain  line  styles,  and  most  line 
font  patterns  are  not  successfully  translated;  so  A/E's 
avoid  putting  section  details  or  material  information 
into  their  CAD  data  sets. 

In  most  cases,  translated  data  sets  have  to  be  edited  in  order  to 
make  them  "visually  equivalent"  on  the  receiving  system. 

As  of  yet,  there  are  very  few  methods  for  monitoring  the  quality 
of  data  set  exchanges  and  for  ensuring  that  the  data  were 
translated  correctly.  A common  complaint  by  CAD  users  is  that 
many  of  the  translator  programs  do  not  output  any  messages  as  to 
individual  entity  translation  problems  and  that  most  translators 
do  not  generate  a translation  error  log  during  execution.  A 
translator  program  should  at  least  tell  the  user  what  entities 
could  not  be  translated. 

An  important  tool  for  improving  the  quality  of  data  set  exchanges 
is  the  monitoring  and  documenting  of  problems  and  successes. 
Some  firms  have  begun  to  record  this  type  of  information,  and 
many  AEC  organizations  have  initiated  new  programs  to  test  and 
refine  their  data  set  exchange  capabilities.  Yet,  an  overriding 
factor  in  construction  projects  is  expedience,  and  the  demands 
for  completing  a job  can  cause  some  of  these  quality  assurance 
procedures  to  be  short-circuited. 

Data  set  verification  procedures  should  ensure  numerical  accuracy 
and  the  usability  of  the  translated  data.  The  method  used  by  most 
AECs  is  to  do  a visual  comparison  between  the  received  "digital 
drawings"  and  the  original  hard  copy  drawings.  This  is  usually 
accomplished  by  plotting  the  translated  data  sets  and  overlaying 
the  plot  on  top  of  the  original. 

Even  if  a visual  inspection  is  successful,  this  does  not  ensure 
that  the  translated  data  sets  are  "functionally  equivalent"  on 
the  receiving  system.  One  example  of  the  potential  for 
functional  degradation  is  when  subfigures  are  translated  into 
separate  vectors  such  that  the  subfigures  can  no  longer  be 
manipulated  as  single  entities  on  the  receiving  systems.  Any 
comprehensive  measure  of  successful  data  set  translation  must 
include  methods  to  assess  the  degree  to  which  the  received  data 
sets  can  be  revised  in  an  effective  manner  on  the  receiving 
system. 

Currently,  most  AEC  firms  have  limited  management  and  control 
procedures  for  the  exchange  of  CAD  data  sets  or  for  the 
coordination  of  CAD  data  sets  with  conventional  hard  copy 
drawings.  The  management  of  CAD  data  set  exchanges  requires 
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controls  on  the  libraries  of  CAD  reference  plans  and  symbols  and 
should  include  comprehensive  archiving  procedures.  Most  firms 
have  minimal  controls  on  reference  libraries,  and  in  some 
projects,  there  are  multiple  sources  for  the  "master  documents" 
being  referenced  by  project  participants. 

A critical  CAD  issue  that  has  not  been  resolved  within  most  AEC 
organizations  is  the  requirement  for  archiving  the  design 
documents,  the  CAD  digital  files,  and  the  audit  trails  of  design 
responsibility.  Additionally,  the  issue  of  archival  in  a neutral 
format  to  avoid  data  loss  due  to  system  updates  has  not  been 
resolved.  "Interface  difficulties  also  need  to  be  anticipated 
when  records  from  the  CAD  system  are  archived,  because  future  use 
may  be  on  a different  system."  [10] 

The  assignment  of  responsibility  for  A/E  design  decisions  usually 
includes  a professional  stamp  with  a dated  signature.  The  signed 
design  document  has  traditionally  become  the  legal  record  for  all 
potential  liability  concerns.  With  the  increasing  use  of  CAD 
data  sets  as  the  primary  repository  of  design  decisions,  AEC 
archival  procedures  must  be  revaluated  so  as  to  digitally  include 
the  audit  trails  of  responsible  individuals  and  all  other 
information  necessary  for  legal  considerations. 

With  conventional  CAD  data  storage  (magnetic  tape  and  disk) , 
there  is  no  easy  way  to  guarantee  that  the  digitally  encoded 
design  documents,  with  the  approval  signatures,  cannot  be  altered 
at  a later  date.  Due  to  this  limitation,  most  organizations  are 
archiving  duplicate  design  documentation,  both  the  digital  data 
sets  and  the  signed  hard  copy  (usually  on  microfilm)  . In 
addition  to  the  costs  of  this  duplication,  such  procedures  may 
lead  to  inconsistencies  in  project  documentation  and  redundant 
version  controls. 

CAD  data  set  translation  can  be  full  of  problems,  and  no  one 
wants  to  take  the  responsibility  for  the  translated  data.  Many 
service  bureaus  are  avoiding  translation  jobs  until  they  are 
confident  as  to  the  reliability  of  the  software  tools.  There  are 
numerous  examples  of  AEC  firms  giving-up  on  translating  data  sets 
and  choosing  to  manually  re-input  the  data. 

Additionally,  the  early  translators  had  marginal  capabilities, 
which  did  not  fully  support  the  requirements  of  the  AEC  industry. 
These  translators  were  expensive  to  maintain  and  to  operate 
(excessive  file  sizes  and  run  times)  . The  documentation  on  many 
translators  is  still  limited.  At  best,  the  documentation  shows 
how  to  run  the  translator,  but  not  how  to  analyze  the  translation 
problems.  Very  few  translators  provide  comprehensive  error 
recovery  capabilities  or  diagnostic  transaction  reporting. 

Another  limitation  on  AEC  CAD  data  set  exchanges  is  the  ambiguity 
and  the  flexibility  of  the  current  IGES  specification.  Since  the 
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vendors  do  not  interpret  the  specification  uniformly,  there  are 
incompatibilities  in  the  mappings  between  the  preprocessor  of  one 
vendor  and  the  postprocessor  of  a different  vendor.  AEC  firms 
(except  for  the  larger)  do  not  have  a budget  for  verifying 
translators  or  to  custom  build  translating  and  archiving 
utilities.  In  order  to  effectively  exploit  the  capabilities  of 
CAD,  the  AEC  industry  requires  a dependable  method  of  data  set 
exchange  and  reliable  translation  tools. 

The  AEC  industry,  having  recently  adopted  CAD  as  a primary  tool, 
is  now  confronting  the  issues  of  compatible  data  formats.  Many 
AEC  firms  recognize  the  importance  of  transferring  "intelligence" 
with  the  graphics  and  are  expanding  their  CAD  capabilities  to 
support  the  exchange  of  project  models  with  their  attached 
databases.  Across  the  full  range  of  large  construction  projects, 
from  major  public  works  projects  to  corporate  facilities,  there 
is  growing  interest  in  full,  project  life  cycle  exchange 
capabilities. 

An  increasing  number  of  clients  are  requesting  the  delivery  of 
their  projects'  documents  in  a specified  data  format  so  that  they 
can  use  them  for  facilities  management  on  the  in-house  CAD 
system.  Major  public  works  projects  are  currently  deciding  how 
to  specify  the  format  for  the  intermediate  transfer  of  CAD  data 
sets  among  subcontractors.  The  Federal  Aviation  Administration 
(FAA)  has  decided  to  require  airports  to  furnish  them  with 
airport  layout  plans  in  IGES  format  by  1987. 

An  interesting  aspect  of  the  "Mobilization  Plan"  for  the  Boston 
Harbor  Tunnel  project  is  that  the  primary  AEC  contractors  are 
also  examining  how  to  get  the  state  to  accept  the  data  sets  as 
the  deliverable  master  document.  Another  major  project  which  is 
also  in  the  midst  of  establishing  the  format  for  AEC  CAD  data  set 
exchanges  is  the  Orlando  International  Airport.  This  project  is 
intended  to  establish  the  data  set  exchange  and  archival 
procedures  for  supporting  operations  for  the  rest  of  the  century. 

As  part  of  this  increasing  understanding  of  the  importance  of 
data  set  exchanges,  numerous  corporations  and  government  agencies 
have  decided  to  adopt  IGES.  Key  reasons  for  these  decisions  are 
that  IGES  allows  AEC  firms  far  more  flexibility  in  how  they  use 
their  CAD  resources  and  that  it  provides  clients  more  flexibility 
in  selecting  AEC  contractors.  The  CERL  Technical  Report  on 
graphics  translators  concludes  that  "a  translator  format  is 
needed  that  can  support  both  current  drafting  systems  and  future 
modeling  systems.  To  date,  IGES  is  the  only  format  that  provides 
that  capability.  ...  Only  IGES  has  the  technical  capability  to 
capture  the  building  and  site  "model"  and  further,  it  has  the 
largest  following  in  the  industry  as  a whole.  Therefore,  it  is 
expected  to  have  the  best  chance  of  meeting  the  AEC  community':' 
future  needs."  [3] 
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Management  at  many  AEC  firms  have  decided  that  IGES  has  matured 
into  a viable  standard  for  their  projects,  and  some  are  defining 
an  application  subset  of  IGES  for  their  types  of  work.  Recent 
RFPs  for  large  international  projects  have  included  IGES  test 
cases  as  part  of  the  qualification  criteria,  and  some  major  AECs, 
who  have  decided  to  integrate  their  multiple  CAD  operations,  have 
selected  IGES  for  some  internal  data  set  exchanges. 

During  the  past  year,  there  have  been  significant  improvements  in 
the  quality  of  IGES  processors  and  in  the  support  by  the  vendors. 
The  vendors  now  recognize  that  working  together  to  establish  data 
communication  standards  serves  their  strategic  interests. 
"Giving  up  proprietary  secrets  may  be  the  price,  but  the 
potential  is  so  enormous  that  there  should  be  plenty  of 
opportunity  for  all."  [11] 

All  of  these  factors,  along  with  the  increasing  participation  of 
users  and  vendors  in  the  IGES  committees,  are  providing  a viable 
framework  for  the  continued  improvement  of  IGES.  As  more  AEC 
organizations  develop  comprehensive  IGES  implementation 
strategies  and  with  the  continued  improvement  of  the 
specification  and  of  the  translator  software,  IGES  should  provide 
a good  foundation  for  the  majority  of  the  current  digital  data 
set  exchange  requirements  within  the  AEC  industry. 
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5. 


Summary  and  Recommendations 


This  assessment  of  the  current  ability  of  the  AEC  industry  to 
exchange  CAD  data  sets  has  identified  numerous  issues  which 
must  be  resolved  so  as  to  ensure  successful  data  set  exchanges 
and  the  comprehensive  archiving  of  AEC  projects.  In  order  to 
take  full  advantage  of  CAD  and  to  maximize  the  utilization  of 
digital  project  information,  the  AEC  industry  requires  a 
dependable  method  for  digital  data  exchanges. 

It  is  important  to  understand  that,  at  present,  the  successful 
transfer  of  CAD  drawings  between  multiple,  dissimilar  systems  has 
a significant  price.  This  price  is  the  time  spent  to  understand 
each  system's  operations,  the  time  spent  to  understand  the  system 
vendor's  implementation  of  the  translation  software,  the  time 
spent  to  understand  the  error  messages'  meanings  and  their 
consequences,  and  the  resources  required  to  test  and  validate  the 
translators  and  the  data  set  translations. 


5 . 1 Key  Issues 


* The  current  generation  of  translator  software  tools  is 
inadequate  for  comprehensive  AEC  CAD  data  set  exchanges. 
Incomplete  translators,  erroneous  processors,  and  differing 
interpretations  of  IGES  have  prevented  accurate  data  set 
exchanges.  Translator  programs  should  include  editing,  analysis, 
and  transaction  reporting  capabilities.  Their  documentation 
should  show  how  to  run  the  translator  and  how  to  analyze 
translation  problems. 

* The  terminology  of  each  CAD  system  and  of  the  intermediate 
exchange  format  may  be  different,  or  there  may  be  common 
terms  which  are  used  to  convey  different  information.  Data 
set  exchanges  will  often  fail  when  these  inconsistencies  are 

not  resolved.  The  language  and  format  of  the  data  exchange  (such 
as  IGES)  should  be  clearly  defined  prior  to  any  data  set 
exchange . 

* The  use  of  symbols  and  libraries.  Some  CAD  systems  store 
the  complete  description  of  a symbol  at  each  instance,  and  other 
systems  encode  a pointer  to  a permanent  library  in  which  the 
complete  description  is  stored.  In  the  latter  case,  a time- 
stamped  version  of  the  symbol  library  will  have  to  accompany  all 
exchanged  data  sets.  User  defined  associativities,  properties, 
and  entities  should  be  included  in  data  set  exchanges  so  as  to 
minimize  misinterpretation. 
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* Entity  mismatches  between  CAD  systems  and  intermediate 
formats.  CAD  users  can  expect  a mismatch  of  CAD  systems' 
capabilities  and  data  entities.  A native  entity  may  have  no 
direct  equivalent  in  another  CAD  system  (or  multiple  possible 
representations  in  IGES)  and  may  be  translated  into  less 
sophisticated  data  elements.  This  can  result  in  inconsistent, 
inaccurate,  or  inefficient  translations.  It  is  advisable  that 
the  sender  and  the  receiver  establish  common  modeling  conventions 
for  encoding  CAD  information. 

* The  extra  requirements  for  the  configuration  management  of 
multi-system  interaction.  This  issue  has  been  avoided  in  much  of 
the  AEC  industry;  specifically  by  using  direct  translators  for 
the  one-way  transfer  of  data  sets.  Key  concerns  are:  the  use  of 
libraries  of  master  specifications  and  details;  defining  common 
entities  and  functionality;  and  the  exchange  and  control  of  the 
definitions  of  symbols. 

* The  limitations  of  IGES,  in  performance,  ambiguity, 
complexity,  and  capabilities.  Early  versions  required  excessive 
resources,  both  in  actual  processing  time  and  in  storage  costs. 
IGES  is  continuously  evolving,  and  Version  4.0  is  currently  being 
developed.  AEC  organizations  must  understand  the  capabilities 
and  the  limitations  of  IGES. 

* Professional  liability  ramifications  of  digital  exchanges; 
who  assumes  responsibility  for  the  accuracy  and  completeness  of 
the  translated  data  sets.  This  issue  is  not  resolved  in  the  AEC 
industry.  At  present,  all  AEC  firms  consider  CAD  data  sets  as 
supplementary  documentation,  with  the  traditional  hard  copy 
drawings  being  the  "master  documents".  Translated  CAD  data  sets 
must  be  reviewed,  just  as  conventional  drawings  are  inspected 
prior  to  being  stamped  and  delivered. 
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5 . 2 Recommendations 


* AEC  organizations  should  establish  standardized  operating 
procedures  which  coordinate  the  use  of  CAD  and  manual 
documentation  / drawings.  Few  firms  have  fully  resolved  these 
issues.  Some  key  concerns  are:  predefined  project  modeling 
conventions  (operations,  sheet  layout,  layer  assignments) ; single 
source  of  standard  symbols;  change  control  and  problem  resolution 
procedures;  the  ability  to  segment  files  for  efficient  updating, 
and  comprehensive  data  set  archival  procedures. 

* AEC  organizations  should  document  the  complete  data  flow  in 
exchanges  (operator  to  operator,  intended  future  uses  of  the 
information,  and  archival  requirements) . It  is  essential  to 
document  what  information  needs  to  be  exchanged  and  by  what 
means.  Currently,  very  few  AEC  firms  have  documented  data  set 
exchange  procedures,  translation  audit-trails,  or  translation 
start-up  test  plans.  Each  of  these  play  a critical  role  in 
ensuring  the  quality  of  the  translations. 

* Comprehensive  data  translation  quality  assurance  programs 
and  evaluation  criteria,  for  monitoring  the  quality  of  the 
translated  data  (accuracy  and  functionality) , should  be 
developed.  These  should  include  translation  start-up  and  testing 
procedures.  In  most  AEC  operations,  these  do  not  exist. 

* Recommended  practices  and  guidelines  for  the  use  of  IGES  in 
the  AEC  industry  need  to  be  established.  These  should  include 
translation  verification  procedures,  a library  of  AEC  benchmark 
files,  implementation  guidelines,  and  archival  strategies. 

* Performance  measures  and  detailed  specifications  for  data 
set  translators  must  be  developed.  At  present  the  users  of  CAD 
translation  software  must  test  each  program  for  the  specifics  of 
the  intended  application.  With  functional  measures  and 
specifications,  the  users  could  far  more  easily  assess  the 
quality  of  the  available  translation  packages. 

* A public  program  to  validate  translator  software  and  to 
identify  problems  in  current  implementations  must  be  established. 
The  quality  of  a data  set  exchange  is  dependent  upon  the 
correctness  and  completeness  of  the  translator  implementations. 

A public  validation  program  would  provide  an  uniform  basis  for 
the  objective  evaluation  of  these  products  by  the  AEC  industry 
and  would  generate  valuable  feedback  for  improving  the 
translators  and  the  application  procedures. 
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Appendix  A 


AEC  CAD  DATA  EXCHANGE  QUESTIONS 


Name  of  Company  

Type  of  Business  No.  of  Empl  .... 

Prof  Disciplines  No.  of  Offc  .... 

Address  


Telephone  No. 
Contact  Name 


1.1  Has  your  organization  exchanged  CAD  data  digitally  with 
other  professionals? 

1.2  For  what  types  of  projects? 

1.3  What  kinds  of  CAD  systems  have  been  used  within  your  firm? 

1.4  What  types  of  information  have  been  exchanged  digitally? 

- just  drawings 

- bill  of  materials 

- drawings  with  databases 

1.5  What  were  the  disciplines  of  the  parties  exchanging  data? 

Your  system:  Rec.  systems: 

1.6  Could  the  transferred  data  be  manipulated  on  the  receiving 
system? 

1.7  Did  you  produce  the  transfer  files  or  did  you  use  a job  shop 
/ service  bureau? 

1.8  What  interchange  formats  have  been  used  and  with  which 
systems? 

IGES , Ver.  ISIF 

....  CalComp  ....  DXF 

....  Other,  specify  

1.9  Which  interchange  formats  are  you  currently  using? 

IGES,  Ver. 

....  Other,  specify  

What  determined  this  selection? 

1.10  What  is  your  standard  data  format  for  internal  usage? 
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2.1  How  successful  were  the  data  exchanges  in  a homogeneous 
environment? 

- complete  file  dump  or  selective  transmission 

- difficulties  and  limitations 

2.2  How  successful  were  the  data  exchanges  in  a heterogeneous 

environment;  what  is  received,  with  what  kind  of 
functionality? 

- one-way  transfer  via  direct  translator 

- one-way  transfer  via  "neutral  format" 

- full-cycle,  from  sys  A to  sys  B,  and  back  to  sys  A 

- graphic  and  non-graphic  entities 

- display  information:  line  weight,  fonts,  etc. 

- annotations:  dimensions,  text 

- logical  structure  of  the  data:  associativities, 
subfigures,  and  properties  (data  attached  to  the 
graphic  constructions) 


3 . 1 Does  your  company  have  documented  operating  procedures  as 
defined  for  CAD  use? 

3.2  Who  is  responsible  for  the  accuracy  and  completeness  of  the 
digitally  translated  drawings  (or  CAD  model)? 

3.3  How  are  the  definitions  of  symbols,  that  are  used  in  the  CAD 
drawings,  stored  and  exchanged  between  systems? 

- stored  with  the  CAD  drawings  as  a supplementary  file 

- stored  by  reference  to  an  external  1 standards ' 
library  so  that  when  the  symbol  is  updated,  any 
future  reproduction  of  a drawing  containing  a 
reference  to  that  symbol  is  also  updated?  (helpful 
for  maintaining  company  standards,  but  this  procedure 
may  prevent  the  accurate  reproduction  of  the  archived 
drawing) 

3.4  Is  this  library  of  symbol  definitions  passed  as  a separate 
file  and  then  manually  installed  on  the  receiving  system? 

3.5  Have  you  examined  the  issues  of  archiving  CAD  data  in  a 
neutral  format  to  avoid  data  loss  due  to  system  updates? 


4.1  Are  you  currently  using  any  direct  conversion  translators? 

From  whom?  Who  provides  customer  support  for  using  the 
software? 
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5.1 


What  have  been  your  major  problems  in  using  IGES  to  transfer 
data  between  different  CAD  systems? 

- entity  mismatches  in  dissimilar  implementations 
of  IGES;  specific  entities  not  accurately  processed 

- organization  of  data  : structure  entities 

- handling  of  size  and  scale,  lines  and  text 

- accuracy  of  placement 

- imprecise  values  generated  by  translation  matrix 

- error  recognition  and  recovery 

5.2  Have  you  documented  the  errors  and  problems  that  have  been 
identified?  Compiled  a list  of  current  fixes  / resolutions? 

5.3  To  what  degree  do  your  IGES  processors  comply  with  Ver.  2.0? 

5.4  What  useful  entities  are  not  mapped  into  or  out  of  the  IGES 
file  by  your  current  processors  (pre  and  post)? 

- geometry,  annotations,  connectivity 

5.5  Is  documentation  developed  to  define  common  entities, 
supported  by  both  CAD  systems,  so  as  to  avoid  using 
unsupported  entities? 

5.6  Do  your  IGES  processors  terminate  upon  encountering 
unsupported  or  incorrect  entities? 

5.7  How  extensively  is  the  START  section  of  your  IGES  files  used 
by  the  sender  to  insert  messages  to  be  read  by  the  human 
receiver? 

- notes  on  matching  levels,  e.g.,  various  types  of 
information  be  constrained  to  appear  on  fixed  levels 

5.8  Is  there  a summary  report  or  translation  log  produced 
by  the  IGES  processors? 

- an  information  message  on  the  status  of  the  process, 
on  the  actions  completed,  and  the  errors  identified 

5.9  Do  you  have  to  edit  any  of  the  files  (orig.,  IGES,  or  post-) 
to  obtain  comparable  (the  intended)  functionality  on  the 
receiving  system? 

- are  entities  or  attributes  changed  to  accommodate  the 
'target'  system 

6.1  Have  you  developed  any  test  case  drawings  for  validating 
your  digital  data  exchanges? 

6.2  Do  you  use  any  software  tools  for  validating  and  diagnosing 
IGES  files  or  processors? 

- conformance  testing  : to  ensure  that  individual 
entities  and  data  items  are  accurately  processed 

- entity  analysis  and  functional  checking 
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6.3  Do  you  use  full-cycle  tests  as  a start-up  procedure  for  new 
projects  using  dissimilar  CAD  systems? 

6 . 4 What  are  your  methods  of  measuring  and  monitoring  the 

success  of  digital  data  transfers  (e.g.,  90  percent 

complete) ? 

- file  verification  methods 

- graphical  and  functional  checks 


7 . 1 How  do  you  evaluate  translator  software? 

- required  capabilities;  acceptance  criteria 

- validation  criteria;  accuracy  and  functionality 

- performance  measurement  (benchmark  tests,  test  cases) 

7.2  How  would  you  describe  the  quality  of  current  translator 
software  and  of  the  supporting  documentation? 

7.3  Do  you  think  there  is  a significant  need  to  improve  the 
current  generation  of  IGES  processors? 

7.4  Have  you  discussed  these  limitations  with  the  vendors  or 
requested  that  they  make  improvements  to  their  IGES 
processors? 


8.1  Do  you  plan  to  use  any  other  translators  within  the  next 
2 years?  If  yes,  please  specify 

8.2  Do  you  plan  to  expand  your  current  levels  of  digital  data 
interchange  during  the  next  two  years? 


8.3  What  do  you  consider  to  be  the  prime  reasons  for  your 
operation/development  of  interchange  facilities? 


. . . . To  optimize  existing 
CAD  resources 

. ...  To  improve  project  team 
coordination/commun . 

. . . . Other 


. . . . In  response  to  client 
demands 

. . . . To  prepare  for  future 

work/expand  CAD  resources 
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